home *** CD-ROM | disk | FTP | other *** search
- >
- > Pictures
- > ========
-
- > It seems sensible to support a variety of formats: TIFF, GIFF, DIBs
- > Fax group III/IV, CGM etc. The idea of embedded objects which return their
- > size and can display themselves at a given location seems appropriate.
- >
- > The client doesn't know in advance about these embedded objects, it therefore
- > makes sense for the server to be able to append them to the requested html
- > document so as to avoid a further network loop delay for retrieving them.
- >
- > Dave Raggett
- >
- > HP Labs, Bristol, UK. (dsr@hplb.hpl.hp.com) +44 272 228046
-
-
- I've been through this line of thought in a hypertext/electronic book project.
- Yes, it's more efficient to include the graphics in the HTML data stream, but
- only if you just have one version (format) for each graphic.
-
- We found it best in the long run to provide our embedded graphics in several
- formats, and allow the client to choose the format most appropriate for its
- output device (e.g. 8-bit vs 24-bit colour, Postscript if the device supports
- it, WMF if the client is running the Microsoft Windows version of the viewer
- program, etc).
-
- The server sends a list of available formats and the client requests the
- graphic file that it prefers. This permits the best available graphic quality
- on each of several possible output devices, but imposes an extra network delay.
- Still, graphic files tend to be pretty big, so the extra delay is only a few
- % of the file's download time.
-
-
- Bob Wildfong bobw@csg.uwaterloo.ca
- Waterloo, Ontario bobw@csg.waterloo.edu
- #include <stddisclaimer.h>
-
-
-